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(57) A system and method for merchant function as- 
sumption of Internet checking and savings account 
transactions enables a service provider to take over all 
merchant type transactions and provide a merchant, 
such as an Internet merchant, with an approved order 
and appropriate credit for the transaction. A service pro- 
vider server receives an electronic check or a payment 
instruction for the merchant from a customer. The pay- 
ment instruction includes, for example, the originator's 



digital certificate and payment and purchase informa- 
tion, including the originator's checking or savings ac- 
count number The payment instruction is automatically 
sent to a customer's bank's server, which confirms the 
availability of funds for the payment A confirmation of 
the availability of funds is automatically sent to the mer- 
chant, and a credit for the payment is automatically sent 
to the merchant's account. In addition, the service pro- 
vider can consolidate order and settlement transactions, 
which saves transaction costs for the merchant. 
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Description 

Cross Reference to Related Applications 

[0001] This application claims the priority of appli- 
cant's co-pending application having U.S. Serial No. 
60/098,196 filed August 27, 1993, incorporated herein 
by this reference, and applicant's co-pending utility ap- 
plication having U.S. Serial No. 09/237,739 filed Janu- 
ary 26, 1 999, incorporated herein by this reference. This 
application also relates to applicant's co-pending utility 
application entitled "System and Use for Correspondent 
Banking" filed August 27, 1999, incorporated herein by 
this reference. 

Field of the Invention 

[0002] The present invention relates generally to the 
field of banking systems and Internet transactions, and 
more particularly, to a system that allows a service pro- 
vider to perform merchant functions in utilizing checking 
and savings accounts in Internet transactions. 

Background of the Invention 

[0003] With the increasing commercialization of the 
Internet, methods of performing payment transactions 
are becoming well known and new payment methods 
are desired. In an effort to expand the available sources 
of payment, methods have been developed to utilize 
checking and savings account funds to perform Internet 
transactions. Some methods allow the use of "electronic 
checks" to perform transactions. 
[0004] There are a number of problems, however, as- 
sociated with current electronic check methods. For ex- 
ample, since the flow of the current electronic checks 
replicates the flow used lor paper checks, the merchant 
is unsure if the electronic check will be paid and there- 
fore delays shipment of the goods to the customer for 
many days. To the customer, despite the transaction 
having the appearance of being on-line, it takes several 
days for his account to be charged. Another scheme re- 
quires the customer to deposit funds into a trusted third 
party's account before the customer can perform a 
transaction. Lastly, schema which can give on-line ap- 
provals are under development. 
[0005] For a customer to be able to use the currently 
available electronic checks, the customer must be a 
member of a bank or financial institution that offers this 
service. Over the next 5 to 10 years, however, only a 
handful of financial institutions are estimated to partici- 
pate in issuing electronic checks or the more efficient 
"electronic payment instructions." Because of this limit- 
ed participation, the majority of customers will not have 
access to electronic checks or electronic payment in- 
structions. Thus, the number of purchasers that a mer- 
chant can attract and serve with an electronic check or 
an electronic payment instruction option is limited. 



[0006] Additionally, for example, not only must the 
customer be a member of a participating financial insti- 
tution, but the merchant must also set up procedures for 
these types of transactions to deal with the limited 

s number of participating financial institutions. Due to the 
limited number of customers who would utilize this pay- 
ment method, a merchant may be discouraged from ex- 
pending the time and money to establish such a system. 
[0007] Further, these new Internet checking and sav- 

10 ings account transaction options present the merchant 
with a whole new set of responsibilities. Not only must 
the merchant establish new procedures to monitor and 
fulfill these orders, they must also keep track of verifica- 
tions and credits. Many merchants do not want to deal 

is with these Issues or cannot afford to hire and train per- 
sonnel who are able to handle and monitor these new 
functions. 

[0008] Therefore, a solution to these problems is 
needed to improve the utilization and acceptance of In- 
20 ternet transactions using checking and savings ac- 
counts by merchants. 

Summary of the Invention 

25 [0009] It is a feature and advantage of the present in- 
vention to provide a system and method for merchant 
function assumption of Internet checking and savings 
account transactions which enables a service provider 
to take over certain merchant type functions and to pro- 

30 vide the merchant with an approved order and appropri- 
ate credit for the transaction. 
[0010] It is a further feature and advantage of the 
present invention to provide a system and method for 
merchant function assumption of Internet checking and 

35 savings account transactions which enables a service 
provider to consolidate order and settlement transac- 
tions for a merchant thai enables the merchant to save 
the transaction costs for the merchant. 
[0011] To achieve the stated and other features, ad- 

40 vantages and objects, an embodiment of the present in- 
vention provides a system and method for merchant 
function assumption of Internet checking and savings 
account transactions which enables a service provider 
to take over certain merchant type functions and to pro- 

45 vide the merchant with an approved order and appropri- 
ate credit for thetransaction. Further, an embodiment of 
the present invention enables a service provider to con- 
solidate order and settlement transactions for a mer- 
chant that saves transaction costs for the merchant. 

50 [0012] In an embodiment of the present invention, a 
service provider receives an order from a customer that 
is sent to a merchant. The service provider can be a fi- 
nancial institution, such as a service providing bank 
(hereinafter referred to as "service provider"). The order 

55 comprises, for example, the customer's digital certifi- 
cate and purchase and payment information, including 
the customer's checking or savings account number. 
The service provider opens the order and verifies the 
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digital certificate and payment information. The service 
provider sends a message to the bank indicated by the 
customer's payment instruction to verify and debit the 
customer's account if the amount of the transaction 
does not exceed the account balance. 
[0013] In an embodiment of the present invention, the 
customer's bank sends a message back to the service 
provider verifying or denying the debited amount. De- 
pending on the customer's bank's message, the service 
provider then sends a message to the merchant to fill or 
deny the order Further, the service provider insures that 
the merchant's bank receives an Automated Clearing 
Hours (ACH) credit if the order is approved. Finally, the 
service provider may send a message back to the cus- 
tomer that confirms, denies, or requests more informa- 
tion regarding the order. 

[0014] Additionally, in an embodiment of the present 
invention, the service provider may consolidate order 
and settlement transactions. For example, rather than 
receiving individual payments, the service provider in- 
sures that the merchant receives one consolidated ACH 
payment covering all orders over a certain time period. 
The service provider may then give the merchant a 
check list or automated files for cross-checking pay- 
ments with orders 

[001 5] I n another variation in the process flow for an 
embodiment of the present invention, for example, the 
service provider can first receive the ACH credit before 
forwarding it to the merchant's bank. Similarly, the serv- 
ice provider may directly receive the customer order be- 
fore it ever gets to the merchant. The present disclosure 
is intended to cover all such variations and modifications 
of the present invention. 

[0016] In particular, an embodiment of the present in- 
vention makes use of computer hardware and software, 
such as a customer's processor or PC with modem for 
communicating, for example, with a merchant's on-line 
terminal or a service provider's server over the Internet. 
The service provider's server may also run an Internet 
website for the merchant. Further, the service provider's 
server communicates over the Internet, for example, 
with one or more of the merchant's on-line terminal, the 
merchant's financial institution server, and the custom- 
er's financial institution server. The service provider's 
server assumes at least one merchant function in a fi- 
nancial transaction, such as an Internet website trans- 
action, between the merchant and the customer. For ex- 
ample, the service provider's server receives informa- 
tion about the financial transaction for the merchant, au- 
tomatically identifies the intended recipient of the infor- 
mation, and automatically sends the information to the 
intended recipient for the merchant. 
[0017] In an electronic check aspect for an embodi- 
ment of the present invention, the customer at the cus- 
tomer's processor makes a purchase on the merchant's 
Internet website hosted, for example, by the service pro- 
vider's server and uses software on the customer's proc- 
essor to prepare and send an electronic check for the 



purchase price over the Internet to the service provider's 
server for the merchant. The service provider's server 
receives the electronic check for the merchant and au- 
tomatically reformats the electronic check to a format 

5 which can be understood at the merchant's on-line ter- 
minal. The service provider's server automatically en- 
dorses the electronic check for the merchant, automat- 
ically prepares a deposit for presentation of the en- 
dorsed check to the merchant's bank's server, and au- 

10 tomatically sends the deposit and endorsed electronic 
check over the Internet to the merchant's bank's server 
The merchant's bank's server receives the endorsed 
electronic check, automatically creates an ACH debit to 
the customer's bank's server for the customer's account, 

f s automatically posts the credit to the merchant's account, 
and automatically makes the details of the credit known 
to the merchant. 

[001 8] In a 2-flow model aspect for an embodiment of 
the present invention, the customer at the customer's 

20 processor makes a purchase on the merchant's Internet 
website hosted, for example, by the service provider's 
server and uses software on the customer's processor 
to prepare and send a payment instruction via e-mail or 
HTML page for the purchase price over the Internet to 

25 the service provider's server for the merchant. The serv- 
ice provider's server receives the payment instruction 
for the merchant and automatically sends the payment 
instruction with a request for payment over the Internet 
to the customer's bank's server The customer's bank's 

30 server receives the payment instruction and request for 
payment and automatically confirms that sufficient 
funds are available for the payment instrument in the 
customer's account, automatically sends an approval of 
the payment instruction to the service provider's server 

35 for the merchant over the Internet, and automatically 
sends an ACH credit for the payment according to the 
payment instruction to the merchant's bank for the mer- 
chant's account. 

[001 9] In this aspect of an embodiment of the present 

40 invention, the service provider's server receives and au- 
tomatically reformats the approval of the payment in- 
struction to a format which can be read at the merchant's 
on-line terminal and sends the reformatted approval of 
the payment instruction over the Internet to the mer- 

45 chant's on-line terminal. Upon receipt of the reformatted 
approval of the payment instruction, the merchant ships 
the goods. When the merchant's bank's server receives 
the ACID credit, it automatically posts the credit to the 
merchant's account and automatically makes the details 

50 of the credit known to the merchant. 

[0020] In another Z-flow model aspect for an embod- 
iment of the present invention, the service provider's 
server receives credits for the merchant for various cus- 
tomers from the customers' banks' servers. Rather than 

55 generating an ACH credit to the merchant's bank's serv- 
er for the merchant's account each time a credit is re- 
ceived, the service provider's server accumulates these 
credits for the merchant over a period of time. Periodi- 
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cally, the service provider's server generates a single 
ACH credit or wire transfer for the accumulated or con- 
solidated credits at one time to the merchant's bank's 
server for the merchant's account in order to save trans- 
action costs to the merchant. 
[0021] Additional objects, advantages and novel fea- 
tures of the invention will be set forth in part in the de- 
scription which follows, and in part will become more ap- 
parent to those skilled in the art upon examination of the 
following, or may be learned by practice of the invention. 

Brief Description of the Drawings 

[0022] 

Fig. 1 is a schematic diagram which illustrates an 
example overview of key components and the flow 
of information between the key components for a 
prior art electronic check or e-check model for an 
Internet transaction; 

Fig, 2 is a schematic diagram which illustrates an 
example overview of key components and the flow 
of information between the key components for a 
prior art Z-flow direct presentment model for an In- 
ternet transaction; 

Fig. 3 is a schematic diagram which illustrates an 
example overview of key components and the flow 
of information between the key components for the 
assumption of merchant functions by a service pro- 
vider in the e-check process for an embodiment of 
the present invention; 

Fig 4 is a flow chart which amplifies the flow of in- 
formation shown in Fig. 3 and provides further detail 
regarding an example of the assumption of mer- 
chant functions by the service provider in the e- 
check process for an embodiment of the present in- 
vention; 

Fig. 5 is a schematic diagram which illustrates an 
example overview of key components and the flow 
of information between the key components for the 
assumption of merchant functions by a service pro- 
vider in the Z-flow process for an embodiment of the 
present invention; 

Fig. 6 is a flow chart which amplifies the flow of in- 
formation shown in Fig. 5 and provides further detail 
regarding an example of the assumption of mer- 
chant functions by a service provider in the Z-flow 
process for an embodiment of the present inven- 
tion; 

Fig. 7 is a schematic diagram which illustrates an 
example overview of the key components and the 
flow of information between the key components for 
a consolidation of credits aspect of the assumption 
of merchant functions by the service provider in the 
Z-flow process for an embodiment of the present 
invention; and 

Fig. 8 is a flow chart which amplifies the flow of in- 
formation shown in Fig. 7 and provides further detail 



regarding an example of the consolidation of credits 
aspect of the assumption of merchant functions by 
the service provider in the Z-flow process for an em- 
bodiment of the present invention. 

s 

Detailed Description 

[0023] Fig. 1 is a schematic diagram which illustrates 
an example of key components and the flow of informa- 
10 tion between the key components for a prior art elec- 
tronic check or e-check model for an Internet transac- 
tion. Referring to Fig. 1, the e-check model is designed 
basically like a traditional paper check but using com- 
puter hardware and software, for example, by a custom- 
's er at the customer's personal computer (PC) or proces- 
sor with modem 2 for issuing the e-check and sending 
the e-check 100 to the merchant's on-line terminal 4 
over the Internet6. The e-check model also involves use 
of computer hardware and software at the merchant's 
so on-line terminal 4 for endorsing the e-check and sending 
the endorsed e-check 102 to the merchant's bank's 
server 8. The merchant's bank's server 8 then assures 
an Automated Clearing House (ACH) or Electronic 
Check Presentment (ECP) debit 10 of the customer's 
25 account with the customer's bank to the customer's 
bank's server 12 over the ACH or ECP system. 
[0024] Fig. 2 is a schematic diagram which illustrates 
an example of key components and the flow of informa- 
tion between the key components for a prior art Z-flow 
30 direct presentment model for an Internet transaction. 
Aspects of the Z-flow model include, for example, use 
of customer software on the customer's PC or processor 
2 by the customer, use of merchant software by the mer- 
chant at the merchant's on-line terminal 4 t use of paying 
35 bank software by the customer's bank on the customer's 
financial institution server 1 2, and the ACH system for 
assuring an ACH credit 1 4 to the merchant's bank 8 for 
the merchant's account with the merchant's bank. An- 
other aspect of the Z-flow model can be the use of digital 
40 certificates or other suitable encryption or security de- 
vice to authenticate the identity of the customer, for ex- 
ample, for the customer and the merchant. 
[0025] The Z-flow model makes use of computer 
hardware and software for exchanging payment instruc- 
ts tion information securely over the Internet 6 and ena- 
bling payments, for example, by the customer to a small 
merchant or to another customer or by a business to 
another business. The Z-flow model utilizes a payment 
instrument which uses money in a checking or savings 
50 account to conduct financial transactbns over the Inter- 
net 6. The Z-flow model is sufficiently different from the 
current concept of the e-check that any reference to a 
"check" is misleading. Thus, terminology, such as "pay- 
ment instruction" is used for the payment instrument of 
55 the Z-flow model. 

[0026] The Z-flow model utilizes software to provide 
security, or alternatively, the software security can be 
replaced with a hardware device. The Z-flow model of- 
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fers a payment vehicle for purchases and exchanges of 
value over the Internet 6. Not only can the payment ve- 
hicle for the Z-f low model cause payments to be made, 
but it can also include instructions or payment order in- 
formation. All of this is done securely using digital sig- 
natures and certificates or other methods of encryption 
or other security methods to authenticate the identity of 
the customer with financial settlement occurring over 
the traditional Automated Clearing House (ACH) net- 
work. 

[0027] Referring to Fig. 2, the Z-flow model uses a di- 
rect presentment process. For example, the customer 
at the customer's processor 2, such as the customer's 
PC, makes a purchase from an Internet merchant and 
sends the customer's payment order via e-mail or Hy- 
pertext Markup Language (HTML) page 1 04 to the mer- 
chant at the merchant's on-line terminal 4 over the In- 
ternet 6. The merchant's on-line terminal 4 directly 
presents the payment order 106 to the customer's 
bank's server 12. The customer's bank's server 12 per- 
forms an on-line authentication that the payment in- 
struction came from the customer, that sufficient funds 
are available, and that there are no reasons not to pay 
the payment order. Once this is done, the customer's 
bank's server 1 2 holds or debits the customer's account 
for the amount of the transaction and immediately sends 
an e-mail 108 to the merchant's on-line terminal 4 con- 
firming that the customer's bank's server 12 will send 
out an ACH credit 14 to satisfy the payment order. Si- 
multaneously, the customer's bank's server 12 prepares 
and sends out the ACH credit 14 to the merchant's 
bank's servers. 

[0028] Referring further to the Z-flow model shown in 
Fig. 2, assume that the customer makes a purchase 
from an Internet merchant, such as Barnes & Noble. The 
customer at the customer's processor 2 accesses the 
Barnes & Noble home page and selects a book that the 
customer 2 would like to buy. After the customer selects 
the book, Barnes & Noble calculates the cost plus ship- 
ping and presents the customer with the option to pay 
by credit card or with funds in the customer's checking 
or savings account. If the customer selects checking or 
savings account, the customer's selection activates the 
customer's payment software, which the customer has 
previously loaded onto the customer's processor 2. The 
customer's software, which will accept the payment in- 
formation from either a web page or an e-mail, displays 
a payment order form with the payee's name, such as 
Barnes and Noble, and the date and the amount of the 
purchase filled in, and then asks the customer if he or 
she would like to send a payment to Barnes and Noble. 
[0020] Referring again to the Z-flow model shown in 
Fig. 2, if the customer enters "Yes," the customer's soft- 
ware on the customer's processor 2 composes an e-mail 
or Web response consisting of purchase order informa- 
tion, a payment instruction, an assigned and consecu- 
tively issued serial number, the customer's e-mail ad- 
dress, the customer's digital signature or other suitable 



encryption device which prevents the information from 
being changed, and the customer's digital certificate. 
The customer's digital certificate is issued by a financial 
institution; such as the customer's bank. The digital cer- 
s tificate is a digital document which, through the use of 
public key encryption technology, assures the merchant 
that the customer is who he or she says he or she is and 
provides the name of the customer's bank and the cus- 
tomer's account number. The customer's account 

10 number is encrypted, so that it cannot be seen by the 
merchant. The customer's message may be encrypted 
in such a manner so as to allow the merchant to see the 
purchase order information and the name of the custom- 
er's bank and/or the bank's ABA routing/transit number. 

« The customer's software on the customer's processor 2 
sends this e-mail or HTML page 1 04 to the merchant at 
the merchant's on-line terminal 4 over the Internet 6. 
[0030] Referring still further to the Z-flow model 
shown in Fig. 2, after receiving the customer's e-mail or 

20 web response, the merchant at the merchant's on-line 
terminal 4 assigns a reference number to the order. Us- 
ing the merchant's software at the merchant's on-line 
terminal 4, the merchant digitally signs or uses another 
method to secure a document consisting of the custom- 

25 er's e-mail or HTML page plus the reference number. 
The merchant's software at the merchant's on-line ter- 
minal 4 then composes another e-mail message or 
HTML page consisting of the customer's e-mailorHTML 
page response, the reference number, the merchant's 

30 request for payment, the merchant's digital signature 
and the merchant's digital certificate or other security 
methodology. The merchant's digital certificate is the 
customer's assurance that the merchant is who it says 
it is. The certificate also includes the name of the mer- 

35 chant's bank and the merchant's encrypted account 
number, as well as other certificates stating which bank 
issued the certificate. The resulting message is encrypt- 
ed. The merchant's software at the merchant's on-line 
terminal 4 then sends the encrypted e-mail or HTML 
page 106 directly to the customer's bank's server 12 
over the Internet 6. The merchant's software at the mer- 
chant's on-line terminal 4 knows to which bank to send 
it, because the name of the customer's bank was includ- 
ed in the customer's digital certificate. 

45 [0031] Referring once again to the Z-flow model 
shown Fig. 2, upon receipt of the e-mail or HTML page 
106 by the customer's bank'6 6erver 12, the customer's 
bank's server 12 verifies the validity of the merchant's 
digital certificate, verifies the validity of the customer's 

bo digital certificateor other security methodology, and per- 
forms various security checks, such as ensuring that 
payment has not been stopped and that the payment 
instruction is not a duplicate of a previously paid pay- 
ment instruction. The customer's bank's server 12 also 

55 performs an on-line verification that sufficient funds are 
available. If funds are available, the funds are held on 
line, a debit is prepared for the purchase, and an e-mail 
or HTML page 108 is prepared and sent by the custom- 
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er's bank's server 1 2 over the Internet 6 to the merchant 
at the merchant's on-line terminal 4 telling the merchant 
that the transaction has been approved and that the 
merchant will receive an ACH credit 1 4 for the amount 
ot the purchase, for example, within one business day. 
[0032] Referring still further to the Z-flow model 
shown in Fig. 2, if funds are available, the customer's 
bank's server 12 decrypts the merchant's digital certifi- 
cate, and from that, the customer's bank's software on 
the customer's bank's server 12 prepares the ACH for- 
matted credit 1 4 which is sent to the merchant's bank 8. 
Alternatively, if funds are not available, an e-mail or 
HTML page to the merchant's on-line terminal 4 is pre- 
pared by the customer's financial institution 12 telling 
the merchant that the transaction has not been ap- 
proved, and the customer's bank's server 12 also sends 
an encrypted e-mail or HTML page denying the trans- 
action back to the merchant at the merchant's on-line 
terminal 4. Upon receipt of the transaction approval 1 08 
at the merchant's on-line terminal 4, the merchant, 
knowing that the funds for the goods will be forthcoming, 
can send out the goods immediately. This eliminates 
many days delay, when compared to payment with a tra- 
ditional paper check. 

[0033] Referring once again to the Z-flow model 
shown in Fig. 2, included in the ACH credit 1 4 which the 
customer's bank's server 12 prepares and sends to the 
merchant's bank 12 for the merchant's account at the 
merchant's bank is the information needed to be in com- 
pliance, for example, with Federal Reserve Board Reg- 
ulation E or the National Automated Clearing House As- 
sociation (NACHA) rules and to allow the merchant to 
reconcile each payment with those the merchant was 
accepting. The ACH credit 1 4 stipulates when the funds 
are available in the merchant's financial institution, for 
example, either the same business day, the next, or the 
next. The merchant's bank 8 receives the ACH credit 14 
and posts it to the merchant's account in accordance 
with the included instructions from the customer's 
bank's server 12. The merchant's bank's server 8 makes 
the details of the payment, such as the purchaser's 
name, reference number, date, and amount, available 
to the merchant at the merchant's on-line terminal 4 on 
a periodic account statement or through its on-line serv- 
ices. 

[0034] Another aspect of the Z-flow model direct pre- 
sentment process shown in Fig, 2 is payment by the cus- 
tomer to a small business, such as a small merchant 
over the Internet 6, in which the flow of information is 
analogous to the payment by the customer to the Inter- 
net merchant illustrated in Fig. 2. In this aspect, the small 
business stands in the position of the Internet merchant, 
and the small business's bank stands in the position of 
the Internet merchant's bank. The customer uses the 
customer's existing software facility at the customer's 
processor 2 for receiving e-mail including, for example, 
e-mail bills. The customer receives an e-mail bill from 
the small business and wants to pay the bill. The cus- 



tomer activates the customer's software at the custom- 
er's processor 2, and the customer's software compos- 
es a payment instruction consisting, for example, of the 
billing information, the payment instruction, the custom- 
5 er's e-mail address, and the customer's digital signature 
and certificate. 

[0035] In the payment by the customer to the small 
business aspect of the Z-flow model shown in Fig. 2, if 
the cuslomer wants the payment instruction to be pri- 
10 vate, the customer encrypts the message at the custom- 
er's processor 2 using the payee's public encryption key, 
which was downloaded as part of a web transaction or 
previously obtained from an e-mail transaction. The 
message is encrypted in such a way as to allow the small 
'5 business to see only the information which is needed to 
record the payment accurately. If the customer is simply 
making a payment, the customer manually fills in the in- 
formation. However, for the customer who received the 
bill from the small business by e-mail, the customer's 
software at the customer's processor 2 pre-fills most of 
the information, for example, following industry bill pre- 
sentment standards. The customer's software at the 
customer's processor 2 sends this e-mail to the small 
business's on-line terminal at its address on the bill over 
the Internet 6. After receiving the customer's payment 
instruction from the e-mail, the business either assigns 
a reference number to the payment or uses a number 
from the original bill. The business at its on-line terminal 
composes a message which contains the original pay- 
ment instruction, the reference number and a request 
for payment. The business' software at its on-line termi- 
nal then digitally signs the combined document and at- 
taches its digital certificate, and the document is en- 
crypted. The business's software at its processor sends 
the document to the customer's bank's server 12. The 
business obtains the address for the customer's bank's 
server 12 from the customer's certificate or from an in- 
ternal file. 

[0036] In the payment by the customer to the small 
business aspect of the Z-flow model, upon receipt of the 
e-mail or HTML page by the customer's bank's server 
12, the customer's bank's server 12 verifies the validity 
of the digital certificate or other security methodology 
used of the business, verifies the validity of the digital 
certificate of the customer, performs various security 
checks such as ensuring that payment has not been 
stopped and that the payment instruction is not a dupli- 
cate of a previously paid instruction, and performs an 
on-line verification that sufficient funds are available. If 
funds are available, the funds are held on line, a debit 
is prepared for the purchase, and an e-mail or HTML 
page to the business is prepared by the customer's 
bank's server 12 telling it that the transaction has been 
approved and that it will receive an ACH credit 14 for 
the amount of the purchase, for example, within one 
business day. If lunds are available, the customer's 
bank's server 12 decrypts the digital certificate of the 
business and from that the customer's bank's software 
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prepares the ACH credit 14 to be sent to the businesses 
bank's server. II funds are not available, an e-mail or 
HTML page to the business is prepared telling it that the 
transaction has not been approved. The customer's 
bank's server 12 sends 108 the encrypted e-mail or 
HTML page approving or denying approval of the trans- 
action back to the business's on-line terminal. Upon re- 
ceipt of the e-mail or HTML page by the business, know- 
ing that the funds for the goods will be forthcoming, the 
business can send out the goods immediately. This 
eliminates many days' delay when compared to pay- 
ment with a traditional paper check. 
[0037] In this aspect of the Z-flow model shown in Fig. 
2, included in the ACH credit 14 which the customer's 
bank's server 12 prepares and sends to the business's 
bank's server for the business's account at the busi- 
ness's bank, is the information needed to be in compli- 
ance, for example, with Federal Reserve Board Regu- 
lation E or NACHA rules and to allow the business to 
reconcile each payment with those it accepts. The ACH 
credit 14 stipulates that the funds are available in the 
business's account, for example, either the same busi- 
ness day, the next, or the next. The business's bank re- 
ceives the ACH credit 14 and posts it to the business's 
account in accordance with the instructions which were 
included by the customer's bank's server 12. The busi- 
ness's bank makes the details of the payment, such as 
the name of the customer, reference number, and date 
and amount, available to the business on a periodic ac- 
count statement or through its on-line services. 
[0038] Another aspect of the Z-flow direct present- 
ment model shown in Fig. 2 is payment by the customer 
to a second customer-payee, in which the flow of infor- 
mation is likewise analogous to the flow of information 
in the process of payment by the customer to the Inter- 
net merchant illustrated in Fig. 2. In this aspect, the sec- 
ond customer-payse stands essentially in the same po- 
sition as the Internet merchant, and the second custom- 
er-payee's bank stands essentially in the same position 
as the Internet merchant's bank. In such aspect, the sec- 
ond customer-payee, is provided with software to func- 
tion both as a customer-originator and as a payee. The 
first customer initiates sending a payment instruction 
without previously receiving an e-mail or HTML page. 
For example, in this aspect, the first customer wants to 
send a gift or wants to send money to the second cus- 
tomer who is a child in college. The first customer at the 
customer's processor 2 creates an e-mail and attaches 
the payment instruction to the e-mail. The first customer 
must know the second customer's e-mail address and 
certificate name in order to send the payment instruc- 
tion. The first customer at the customer's processor 2 
digitally signs the payment instruction and attaches his 
or her digital certificate. If the first customer wants the 
payment instruction to be private, he or she must en- 
crypt the message at the customer's processor 2 using 
the public encryption key for the second customer, 
which the first customer previously obtained. The re- 



mainder of the process is the same as in the process of 
the payment by the customer to the small business. 
[0039] An additional payment aspect of the Z-flow di- 
rect presentment model shown in Fig. 2 is a payment by 
5 a small business to anolher small business. Again, the 
flow of information is analogous to the payment by the 
customer to the Internet merchant illustrated in Fig. 2. 
In this aspect, the small business-payer stands essen- 
tially in the position of the customer, the small business- 
10 payer's bank stands essentially in the position of the 
customer's bank, the small business-payee stands es- 
sentially in the position of the Internet merchant, and the 
business-payee' bank stands essentially in the position 
of the Internet merchant's bank. This aspect involves 
15 combining elements of the process of payment by the 
customer to the small business and the process of pay- 
ment by the customer to a second customer-payee. 
[0040] In this aspect ol the Z-flow model shown in Fig. 
2, the business-payer may or may not initiate a payment 
20 instruction on the business-payer's processor as a re- 
sult of an invoice sent via e-mail or HTML page. The 
small business-payer uses its originator software to cre- 
ate an e-mail, which includes information about the pur- 
pose of the payment, and attaches the payment instruc- 
ts tion to the e-mail. The business-payer obtains the e-mail 
address for the business payee from a previous e-mail 
received from the second business, or direct from the 
business-payee, in order to send the payment instruc- 
tion. The business-payer uses its business-payer sott- 
30 ware to digitally sign the payment instruction and attach- 
es its digital certificate. If the business-payer wants the 
payment instruction to be private, it must encrypt the 
message using the public encryption key of the busi- 
ness-payee, which the business-payer previously ob- 
35 tained. The remainder of the process is the same as the 
process of the payment by the customer to a small busi- 
ness. 

[0041 ] Referring now in detail to an embodiment of the 
present invention, an example of which is illustrated in 

40 the accompanying drawings, the system and method for 
an embodiment of the present invention provides, for ex- 
ample, for the assumption by a service provider of cer- 
tain merchant functions in the e-check model. Fig. 3 is 
a schematic diagram which illustrates an example over- 

45 view of key components and the flow of information be- 
tween the key components for the assumption of mer- 
chant functions by a service provider in the e-check as- 
pect for an embodiment of the present invention. Refer- 
ring to Fig, 3, the service provider using a service pro- 

50 vider server 1 6 is a representative for the merchant but 
is otherwise invisible to the other participants in a trans- 
action. In an embodiment of the present invention, the 
service provider's server 1 6 sits between the customer's 
processor 2 and the merchant's on-line terminal 4 and 

55 may run the merchant's website for the merchant. The 
customer thinks he or she is dealing with the merchant 
at the merchant's website, but the customer is actually 
dealing with the service provider's server 16 for the mer- 
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chant. Thus, the merchant is able to use its existing sys- 
tems without modification or new functionality to receive 
transactions via the service provider's server 16. 
[0042] Fig. 4 is a flow chart which amplifies the flow 
ot information shown in Fig, 3 and provides lurther detail 
regarding an example of assumption ol merchant func- 
tions by the service provider in the e-check model for an 
embodiment of the present invention. Referring to Fig. 
4, at S1 , the service provider's server 16 runs the mer- 
chant's website for the merchant. At S2, the customer 
at the customer's processor 2 accesses the merchant's 
website, makes a selection of the merchant's goods or 
services, and uses the customer's software to prepare 
and send an e-check 100 for the purchase. As men- 
tioned, the customer thinks he or she is dealing with the 
merchant, but the customer is actually dealing with the 
service provider's server 16, so the e-check 100 is ac- 
tually sent to the service provider's server 1 6 for the mer- 
chant. At S3, the service provider's server 16 receives 
the e-check and reformats the e-check to a format so 
that the payment information can be read at the mer- 
chant's on-line terminal 4 and sends the reformatted e- 
check 110 to the merchant's on-line terminal 4 over the 
Internet 6 or other mutually agreed to communications 
vehicle. At S4, the service provider's server 1 6 endorses 
the e-check and prepares a deposit to the merchant's 
account. At S5, the service provider's server 16 sends 
the endorsed e-check 1 1 2 over the Internet 6 to the mer- 
chant's bank's server 8. At S6, the merchant's bank's 
server 8 receives the endorsed e-check 112 and then 
creates an ACH or ECP debit 10 to the customer's ac- 
count with the customer's bank. The merchant's bank's 
server 12 posts a credit to the merchant's account and 
makes the details of the payment available to the mer- 
chant on a statement and through its on-line services. 
[0043] The system and method for an embodiment of 
the present invention also provides, for example, for the 
assumption of certain merchant functions in the Z-flow 
model. Fig. 5 is a schematic diagram which illustrates 
an example overview of key components and the flow 
of information between the key components for the as- 
sumption of merchant functions by the service provider 
in the Z-flow model for an embodiment of the present 
invention. Referring to Fig. 5, the service provider is like- 
wise a representative for the merchant but is otherwise 
invisible to the other participants in a transaction. In an 
embodiment of the present invention, the service pro- 
vider's server 16 also sits between the customer's proc- 
essor 2 and the merchant's on-line terminal 4 and may 
run the merchant's website for the merchant. It appears 
to the customer that he or she is dealing with the mer- 
chant at the merchant's website, but the customer is ac- 
tually dealing with the service provider's server 1 6 for 
the merchant. Thus, the merchant is able to use its ex- 
isting systems without modification or new functionality 
to receive transactions via the service provider's server 
16. 

[0044] Fig. 6 is a flow chart which amplifies the flow 



of information shown in Fig. 5 and provides further detail 
regarding an example of the assumption of merchant 
functions by the service provider in the Z-flow model for 
an embodiment of the present invention. Referring to 

s Fig. 6, at S10, the service provider's server 16 runs the 
merchant's website for the merchant. At S11 , the cus- 
tomer at the customer's processor 2 accesses the mer- 
chant's website, makes a selection of the merchant's 
goods or services, and uses the customer's software to 

io prepare and send a payment instruction for the pur- 
chase prices via e-mail or HTML page 1 04 over the In- 
ternet 6 to the service provider's server 16. At S12, the 
service provider's server 16 receives the payment in- 
struction and sends the payment instruction with a re- 
's quest for payment 110 to the customer's bank's server 
12. At S1 3, the customer's bank's server 12 receives the 
request for payment 110, confirms thai sufficient funds 
are available and that there is no reason not to pay the 
payment instruction. 

20 [0045] Referring further to Fig. 6, once this is done, 
the customer's bank's server 1 2 holds or debits the cus- 
tomer's account for the amount of the transaction and 
immediately sends an approval 112 over the Internet 6 
to the service provider's server 16 confirming that the 

25 customer's bank's server 1 2 will send out an ACH credit 
to satisfy the payment instruction. At the same time, the 
customer's bank's server 1 2 prepares and sends out the 
ACH credit 14 to the merchant's bank's server 8. At S 
1 4, the service provider's server 16 receives theapprov- 

so al 1 1 2 and reformats and sends the reformatted approv- 
al 114 to the merchant's on-line terminal 4. At S15, the 
merchant receives the approval 112 at the merchant's 
on-line terminal 4 and ships the goods. At S1 6, the mer- 
chant's bank receives the credit, posts the credit to the 

35 merchant's account, and makes the details known to the 
merchant. 

[0046] Fig. 7 is a schematic diagram which illustrates 
an example overview of key components and the flow 
of information between the key components for a con- 

40 solidation of credits aspect of the assumption of mer- 
chant functions by the service provider in the Z-flow 
process for an embodiment of the present invention. In 
the traditional Z-flow process, each transaction with a 
customer incurs a separate transaction charge for the 

45 merchant, for example, by the merchant's bank, as each 
transaction is treated separately. Referring to Fig. 7, in 
an embodiment of the present invention, the service pro- 
vider's server 1 6 sits between the merchant's on-line ter- 
minal 4 and the merchant's bank's server 8. Typically, 

50 the merchant's on-line terminal 8 is receiving many 
transactions 120 separately from a plurality of custom- 
ers' processors 20. In this aspect of an embodiment of 
the present invention, the service provider's server 16 
consolidates settlement transactions, and rather than 

55 receiving individual credits, the service provider's server 
1 6 assures that the merchant's bank's server 8 receives 
one consolidated ACH credit 14 for the merchant cov- 
ering ail payment instructions 120 over a period of time. 
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Thus, the merchant incurs only a single transaction 
charge for the plurality of transactions 120 rather than 
separate transaction charges for each individual trans- 
action. 

[0047] Fig. 8 is a flow chart which amplifies the flow 
ot information shown in Fig. 7 and provides further detail 
regarding an example of the consolidation of credits as- 
pect of the assumption of merchant functions by the 
service provider in the Z-flow process for an embodi- 
ment of the present invention. Referring to Fig. 8, at S20, 
from time to time, various customers use the software 
on their processors 20 to prepare and send payment in- 
structions (the payment instructions from various cus- 
tomers are shown collectively as 120 in Fig. 8) via e- 
mail or HTML page over the Internet 6 to the merchant's 
on-line terminal 4. At S21 , as a payment instruction is 
received from customers at the merchant's on-line ter- 
minal 4 from time to time, a payment request is auto- 
matically sent for each payment instruction from the 
merchant's on-line terminal 4 (the payment requests for 
the various payment instructions are shown collectively 
as 122 in Fig. 8) over the Internet 6 to the appropriate 
customer's bank's server (the various customer's bank's 
servers are shown collectively as 22 in Fig. 8). 
[0048] Referring further to Fig. 8, at S22, as each of 
the various customer's bank's servers 22 receives a 
payment request from the merchant's on-line terminal 
4, the customer's bank's server confirms sufficient funds 
are available in its customer's account and that there is 
no reason not to pay the payment instruction for its cus- 
tomer, holds or debits its customer's account for the 
amount of its customer's transaction, and immediately 
sends its approval (the approvals for various payment 
instructions are shown collectively as 124 in Fig. 8) to 
the service provider's server 1 6. At the same time, the 
customer's bank sends a credit, for example, by wire 
transfer for its customer's transaction to the service pro- 
vider's server 1 6. The credits received from various cus- 
tomers' banks 22, from time to time, credits are shown 
collectively as 126 in Fig. B. 
[0049] Referring again to Fig. 8, at S23, the service 
provider's server 16 receives the various approvals 124 
and sends them to the merchant's on-line terminal 4 as 
they are received. However, the service provider's bank 
receives and holds the various credits 126 over a period 
of time and consolidates the credits 1 26 and periodically 
generates a single ACH credit 1 4 or wire transfer for the 
consolidated credits to the merchant's bank's server 8 
for the merchant's account. At S24, the merchant's 
bank's server receives the consolidated credit, posts the 
credit to the merchant's account, and makes the details 
needed by the merchant to reconcile the merchant's ac- 
count known to the merchant. 
[0050] Various preferred embodiments of the inven- 
tion have been described in fulfillment of the various ob- 
jects of the invention. It should be recognized that these 
embodiments are merely illustrative of the principles of 
the present invention. Numerous modifications and ad- 



aptations thereof will be readily apparent to those skilled 
in the art without departing from the spirit and scope of 
the present invention. Accordingly, the invention is only 
limited by the following claims. 

5 

Claims 

1. A method for assumption by a service provider of 
10 at least one merchant function in a financial trans- 
action between a customer and a merchant, com- 
prising: 

receiving information about the financial trans- 
it action by the service provider for the merchant; 

automatically identifying an intended recipient 
of the information by the service provider for the 
merchant; and 

automatically sending the information to the in- 
20 tended recipient by the service provider for the 

merchant. 

2. The method of claim 1 , wherein receiving the infor- 
mation about the financial transaction further com- 

25 prises receiving an electronic check for the mer- 
chant. 

3. The method of claim 2, wherein receiving the elec- 
tronic check further comprises receiving the elec- 

30 tronic check by a service provider server. 

4. The method of claim 3, wherein receiving the elec- 
tronic check by the service provider server further 
comprises receiving the electronic check from a 

35 customer's processor over the Internet. 

5. The method of claim 4, wherein receiving the elec- 
tronic check from the customer's processor over the 
Internet further comprises receiving the electronic 

40 check representing a payment by the customer in 
an Internet website transaction with the merchant. 

6. The method of claim 5, wherein receiving the elec- 
tronic check representing the payment by the cus- 

45 tomer in the Internet website transaction with the 
merchant further comprises receiving the electronic 
check representing payment by the customer in the 
Internet website transaction with the merchant at an 
Internet website hosted by the service provider 

50 server for the merchant. 

7. The method of claim 3, wherein receiving the elec- 
tronic check by the service provider's server further 
comprises automatically reformatting the electronic 

55 check for a merchant's on-line terminal. 

8. The method of claim 3, wherein receiving the elec- 
tronic check by the service provider server further 
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comprises automatically endorsing the electronic 
check for the merchant by the service provider serv- 
er. 

9. The method of claim 8, wherein receiving the elec- s 
tronic check by the service provider's server further 
comprises automatically preparing a deposit for 
presentation of the endorsed electronic check for 
the merchant to a merchant's bank's server. 

10 

10. The method of claim 1, wherein receiving the infor- 
mation about the financial transaction further com- 
prises receiving a payment instruction for the mer- 
chant. 

15 

11. The method of claim 10, wherein receiving the pay- 
ment instruction further comprises receiving the 
payment instruction by a service provider server. 

12. The method of claim 11 , wherein receiving the pay- 20 
ment instruction by the service provider server fur- 
ther comprises receiving the payment instruction 
from a customer's processor over the Internet. 

13. The method of claim 12, wherein receiving the pay- 25 
ment instruction from the customer's processor 
over the Internet further comprises receiving the 
payment instruction representing a payment by the 
customer in an Internet website transaction with the 
merchant. 20 

14. The method of claim 13, wherein receiving the pay- 
ment instruction representing payment by the cus- 
tomer in the Internet website transaction with the 
merchant further comprises receiving the payment 55 
instruction representing payment by the customer 

in the Internet transaction with the merchant at an 
Internet website hosted by the service provider 
server for the merchant. 

40 

15. The method of claim 1 , wherein receiving the infor- 
mation about the financial transaction further com- 
prises receiving an approval of a payment instruc- 
tion for the merchant. 

45 

16. The method of claim 15, wherein receiving the ap- 
proval further comprises receiving the approval by 
a service provider server. 

17. The method of claim 16, wherein receiving the ap- so 
proval further comprises receiving the approval 
from a customer's bank's server over the Internet. 

18. The method of claim 17, wherein receiving the ap- 
proval from the customer's bank's server further 55 
comprises receiving a credit by the service provider 
server from the customer's bank's server over the 
Internet. 



1 9. The method of claim 1 B, wherein receiving the cred- 
it by the service provider server further comprises 
consolidating the credit with at least one additional 
credit for the merchant. 

20. The method of claim 1, wherein automatically iden- 
tifying the intended recipient further comprises au- 
tomatically identifying the intended recipient of an 
electronic check for the merchant. 

21. The method of claim 20, wherein automatically 
identifying the intended recipient of the electronic 
check further comprises automatically identifying 
the intended recipient by a service provider server 
for the merchant. 

22. The method of claim 21, wherein automatically 
identifying the intended recipient by the service pro- 
vider's server further comprises automatically iden- 
tifying a merchant's bank's server as the intended 
recipient by the service provider's server. 

23. The method of claim 1 , wherein automatically iden- 
tifying the intended recipient further comprises au- 
tomatically identifying the intended recipient of a 
payment instruction for the merchant. 

24. The method of claim 23, wherein automatically 
identifying the intended recipient of the payment in- 
struction further comprises automatically identifying 
the intended recipient by a service provider server 
for the merchant. 

25. The method of claim 24, wherein automatically 
identifying the intended recipient by the service pro- 
vider server further comprises automatically identi- 
fying a customer's bank's server as the intended re- 
cipient. 

26. The method of claim 1 , wherein automatically iden- 
tifying the intended recipient further comprises au- 
tomatically identifying the intended recipient of an 
approval of a payment instruction for the merchant. 

27. The method of claim 26, wherein automatically 
identifying the intended recipient of the approval fur- 
ther comprises automatically identifying the intend- 
ed recipient by a service provider server. 

28. The method of claim 27, wherein automatically 
identifying the intended recipient by the service pro- 
vider server further comprises automatically identi- 
fying a merchant's on-line terminal as the intended 
recipient. 

29. The method of claim 1 , wherein automatically iden- 
tifying the intended recipient further comprises au- 
tomatically identifying the intended recipient of a 
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credit for a payment instruction for the merchant. 

30. The method of claim 29, wherein automatically 
identifying the intended recipient of the credit further 
comprises automatically identifying the intended re- 
cipient by a service provider server. 

31. The method of claim 30, wherein automatically 
identifying the intended recipient by the service pro- 
vider server further comprises automatically identi- 
fying a merchant's bank's server as the intended re- 
cipient. 

32. The method of claim 1 , wherein automatically send- 
ing the informatbn further comprises automatically 
sending an endorsed electronic check to a mer- 
chant's bank's server for the merchant. 

33. The method of claim 32, wherein automatically 
sending the endorsed electronic check to the mer- 
chant's bank's server further comprises automati- 
cally sending the endorsed electronic check to the 
merchant's bank's server by a service provider's 
server for the merchant. 

34. The method of claim 33, wherein automatically 
sending the endorsed electronic check further com- 
prises automatically sending a deposit for presen- 
tation of the endorsed electronic check with the en- 
dorsed electronic check. 

35. The method of claim 33, wherein automatically 
sending the endorsed electronic check further com- 
prises automatically sending the endorsed elec- 
tronic check over the Internet. 

36. The method of claim 1 , wherein automatically send- 
ing the informatbn further comprises automatically 
sending a payment instruction to a customer's 
bank's server for the merchant. 

37. The method of claim 36, wherein automatically 
sending the payment instruction to the customer's 
bank's server fu rther comprises automatically send- 
ing the payment instruction to the customer's bank's 
server by a service provider server for the mer- 
chant, 

38. The method of claim 1 , wherein automatically send- 
ing the information further comprises automatically 
sending an approval of a payment instruction to a 
merchant's on-line terminal for the merchant. 

39. The method of claim 1 , wherein automatically send- 
ing the information further comprises automatically 
sending a credit for a payment instruction for the 
merchant to a merchant's bank's server. 



40. The method of claim 39, wherein automatically 
sending the credit to the merchant's bank's server 
further comprises automatically sending the credit 
by a service provider server. 

5 

41. The method of claim 46, wherein automatically 
sending the credit by the service provider's server 
further comprises automatically sending the credit 
consolidated with at least one additional credit for 

10 the merchant. 

42. A system for assumption by a service provider of at 
least one merchant function in a financial transac- 
tion between a customer and a merchant, compris- 
es ing: 

means for automatically receiving Information 
about the financial transaction by the service 
provider for the merchant; 
20 means associated with the receiving means for 

automatically identifying an intended recipient 
of the information by the service provider for the 
merchant; and 

means associated with the identifying means 
25 for automatically sending the information to the 

intended recipient by the service provider for 
the merchant. 

43. The system of claim 42, wherein the receiving 
30 means further comprises a service provider server 

coupled to a customer's processor. 

44. The system of claim 42, wherein the receiving 
means further comprises a service provider server 

35 coupled to a customer's bank's server. 

45. The system of claim 42, wherein the identifying 
means further comprises a service provider server. 

40 46. The system of claim 42, wherein the sending means 
further comprises a service provider server coupled 
to a merchant's on-line terminal. 

47. The system of claim 42, wherein the sending means 
45 further comprises a service provider server coupled 

to a merchant's bank's server. 

48. The system of claim 42, wherein the sending means 
further comprises a service provider server coupled 

so to a customer's bank's server. 
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